Eric,
	I think you might have missed that rfc6372 section 6.1.2 is consistent
with RFC4427.  So perhaps it would be best to have a standalone
draft/rfc that updates both rfc6372 and rfc4427 on this specific point
alone.  If this is done, no change to rfc5654 is needed.

Lou

On 5/9/2013 11:40 AM, Eric Osborne (eosborne) wrote:
> Hi Alessandro, see inline.
> 
>> -----Original Message-----
>> From: D'Alessandro Alessandro Gerardo
>> [mailto:alessandro.dalessandro@telecomitalia.it]
>> Sent: Tuesday, May 07, 2013 3:27 PM
>> To: Eric Osborne (eosborne); mpls@ietf.org
>> Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto;
>> ryoo@etri.re.kr; lifang@catr.cn; cts@etri.re.kr
>> Subject: R: PSC: draft-rhd-mpls-tp-psc-priority-00
>>
>> Hi Eric,
>> You wrote "is it appropriate to make this priority swap?"
>> My answer is yes, it shall be done for the reasons explained in liaison
>> 1205, bullet 1.
> 
> Let me paraphrase the three points in those bullets, I want to make sure I understand them:
> 
> a. If the protection path fails then the removal of the FS will not be seen because the channel used to provide it is gone.
> b. If there is SF-P and FS is issued by accident then this will cause an outage, which is Bad
> c. (points to Annex 1): similar to (a) above, the loss of the protection channel means there will be an inconsistency in the protection state
> 
> Is that an accurate paraphrase?
> 
>> You wrote "- what do we need to change?  rfc5654?  rfc4427?  "
>> No I don't believe it is required to change any RFC but RFC 6378
> 
> To me this decision is a matter of process rather than of technical behavior.  
> I believe the current set of opinions is this:
> 
> a) some believe that rfc4427 requires the current set of priorities, as per LS1174 point #1 (http://datatracker.ietf.org/liaison/1174/)
> b) some believe it does not, and that rfc6378 misinterpreted rfc4427
> 
> I think we all agree that the chain here is: 6378 must obey 5654, and that 5654 requires 4427.
> 
> So it's going to come down to - is 4427 written wrong but interpreted correctly, or written correctly but misinterpreted?
> If we decide the former, we need to change 4427 and/or 5654 to clarify the requirement.
> If we decide the latter, we do not need to change 4427 and can probably just change 6378.
> 
> Does that sound right?
> 
> 
> 
> eric
> 
>>
>> Best regards,
>> Alessandro
>>
>> ------------------------------------------------------------------
>> Telecom Italia
>> Alessandro Gerardo D'Alessandro
>> Transport Innovation
>> Via Reiss Romoli, 274 - 10148 Torino
>> phone:  +39 011 228 5887
>> mobile: +39 335 766 9607
>> fax: +39 06 418 639 07
>>
>>
>> -----Messaggio originale-----
>> Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di
>> Eric Osborne (eosborne)
>> Inviato: mercoledì 17 aprile 2013 14:16
>> A: mpls@ietf.org
>> Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00
>>
>> This thread is for discussing draft-rhd-mpls-tp-psc-priority-00.  In
>> brief, the draft proposes swapping the priorities between FS and SF-P
>> (see section 4.3.2 of rfc6378).  This proposed swap has a long history,
>> dating back to when PSC was an ID.  For some history, see
>>
>> http://datatracker.ietf.org/liaison/1229/
>> and
>> http://datatracker.ietf.org/liaison/1234/
>>
>> The questions that I think are relevant here are:
>>
>> - is it appropriate to make this priority swap?
>>   - are there alternative approaches?
>>   - what do we need to change?  rfc5654?  rfc4427?
>> - if we don't make the change, does this expose implementation to
>> problems?
>> - if we do make the change, how do we go about it?
>>
>> but of course any and all discussion is welcome.
>>
>> As with the other threads I'm going to leave my two cents out of this
>> introductory email but I'll chime in when discussion starts.
>>
>>
>>
>>
>>
>> eric
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
>> persone indicate. La diffusione, copia o qualsiasi altra azione
>> derivante dalla conoscenza di queste informazioni sono rigorosamente
>> vietate. Qualora abbiate ricevuto questo documento per errore siete
>> cortesemente pregati di darne immediata comunicazione al mittente e di
>> provvedere alla sua distruzione, Grazie.
>>
>> This e-mail and any attachments is confidential and may contain
>> privileged information intended for the addressee(s) only.
>> Dissemination, copying, printing or use by anybody else is unauthorised.
>> If you are not the intended recipient, please delete this message and
>> any attachments and advise the sender by return e-mail, Thanks.
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> 
>